Date: Sat, 9 Apr 94 04:30:25 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #105 To: Ham-Digital Ham-Digital Digest Sat, 9 Apr 94 Volume 94 : Issue 105 Today's Topics: Difference: 1270B and 1270C?? FCC Packet Message Forwarding Is KA9Q telnet correct? (virtual terminal) NTS---Hank Oredson notes RTTY for a beginner. sexually explicit talk TCP/IP <--> FBB ax.25 link TCP/IP from car w/PK-88 (Help) Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 06 Apr 1994 12:56:32 +0600 From: ihnp4.ucsd.edu!galaxy.ucr.edu!library.ucla.edu!agate!howland.reston.ans.net!math.ohio-state.edu!news.acns.nwu.edu!ftpbox!mothost!delphinium.cig.mot.com!mac-am-14.cig.mot.com!user@network. Subject: Difference: 1270B and 1270C?? To: ham-digital@ucsd.edu What is the difference between the MFJ 1270B and the "new" 1270C? Thanks, Marc Holdwick - N8KWX ------------------------------ Date: 08 Apr 1994 16:03:22 GMT From: pa.dec.com!nntpd.lkg.dec.com!nntpd.bb.dec.com!waf@decwrl.dec.com Subject: FCC Packet Message Forwarding To: ham-digital@ucsd.edu But what constitutes "atuhenticating" the source station? -- -- Bill Freeman, waf@zk3.dec.com, KE1G, PP-SMEL-IA(ME VFR only) N4365Z USABDA, MassABDA (novice modern), NMRA, rounds, squares, bad jokes. Telemarketing: Do more than just say no, write saying you seek other vendors. ------------------------------ Date: Thu, 7 Apr 1994 20:34:23 +0000 From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!demon!llondel.demon.co.uk!dave@network.ucsd.edu Subject: Is KA9Q telnet correct? (virtual terminal) To: ham-digital@ucsd.edu Try looking at the 'eol' command on KA9Q. I think there is some trickery involved to switch from the DOS newline to the Unix newline convention (similar to transferring ASCII files via ftp) which might even be done with some negotiation when opening the telnet connection. Possibly some flavours of software do it better than others? Dave -- ***************************************************************************** * G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on * * dave@llondel.demon.co.uk Internet * until the end. Then stop. * * g4wrw@g4wrw.ampr.org Amprnet * (the king to the white rabbit) * ***************************************************************************** ------------------------------ Date: Fri, 8 Apr 1994 14:10:34 GMT From: elroy.jpl.nasa.gov!swrinde!emory!wa4mei!ke4zv!gary@ames.arpa Subject: NTS---Hank Oredson notes To: ham-digital@ucsd.edu In article <22259.tao@maroon.tc.umn.edu> writes: >Hank, an old time friend from the Twin Cities now in "exile" in Oregon >said about the BBS/NTS interface: >> >>'But in any case, stop trying to force fit things that were appropriate >>40 or more years ago to the present reality.' >>... >> >> ... Hank > >Of course Hank is right about this. The "regular" NTS, something Hank and I >and many others participated in years ago, was and is a training ground to >learn message handling in a format useful in emergencies and for military >use. > >The problem is, the telephone is so ubiquitous and so low cost, that >handling messages that may or may not get delivered rates right up there >with exchanging re-tries on HF packet. (STA or otherwise). [snip] >Forty years ago the communications world was different and the choices >available and the choices made were different too! Our current culture >really does not lend itself to the classic NTS format and activity and, as >a result, we probably can expect it to gradually fade away. > >If you have thoughts on where we may be evolving to I would very much like >to hear them. As much as I would like to see amateur radio continue to provide useful message handling systems for emergencies, Mr. Olson is right, our methods and modes are obsolete in the modern world, except in very rare and limited cases. If we are to be of help in this arena, and I think we still can be, then we have to rethink our approach. For those of us interested in digital modes, the challenge is to seamlessly internetwork with the "information superhighway". The NTS message format is not compatable with that goal because it was intended to be handled with human interpretation and human intervention. We need to re-examine the way we handle messages, and the format in which they are cast. Key areas we need to examine are format, addressing, routing, and assured delivery. RFC822 or X400 messaging standards give us frameworks for messages that can transparently move over many disjoint networks. The ticklish problems we face are in resolving a message addressee to a machine address, and in dynamically building routing systems that can deal with our often transient systems and links. (We should be able to act as bridges across broken commercial links in time of emergency without having to handle messages by hand, and we should be able to utilize commerical networks for part of our delivery system, again without need of by hand manipulation.) Because of the disjoint nature of our networks, and because realtime connectivity across the networks is a rare thing, we can't depend on a level 4 transport protocol like TCP to meet our end to end message handling needs, though it's useful in assuring delivery across intermediate connected segments of the networks. Nor can we use IP to route our messages because there's no dynamic route building mechanism in current implementations that can handle transient connectivity and the dynamic message addressee to destination machine address mapping we require, though we can use IP across connected segments of the networks while forwarding our messages. But messages of the types we're considering are at a higher level of abstraction than is addressed by TCP/IP. That's where the BBS and it's Sysop have tried to fill the gap. Instead of sending and receiving packets, the BBS sends and receives whole messages. Instead of resolving packet addresses and developing dynamic packet routes, the BBS must resolve message destination address mappings, and develop dynamic message delivery routes. (SMTP is a method that does this, but it can't cope with the disjoint nature of our amateur networks.) It's the same idea as what TCP/IP does on the packet level in semi-realtime, so we can apply many of the concepts developed for TCP/IP in our message handling systems. But there are significant differences too. Mainly because we can't expect timely end to end response, we have to alter the way we do name service resolution of addresses, and because of the disjoint store and forward nature of the network segments, we have to change the way we guarantee end to end integrity and delivery. The one thing we can't do is allow copies of messages to be diverted to alternate delivery systems in mid-stream. Daniel gave us a way to kill duplicates at a destination machine, so having duplicates circulating inside our networks isn't a serious concern. For example we could try a flood algorithm in order to insure rapid delivery of a priority message to a destination machine. Daniel's mechanism of message hashes would kill later arriving duplicates. But if we allow the messages to be visible at intermediate machines, they can be diverted to alternate delivery mechanisms, such as voice, RTTY, or CW NTS nets. And subsequently delivered, or reinserted into the packet system in a form that defeats hash checking, or with altered routing to a different destination machine, so that they are taken and delivered again. So my first concrete suggestion to the BBS authors is to make NTS messages invisible to potential NTS traffic takers on intermediate machines. My second concrete suggestion is that NTS messages on destination machines should auto-kill when the user who downloads it logs off the system, and an automatic service message be generated back to the originating BBS listing the call of the user taking the traffic. NTS users must be educated that if they download a piece of NTS traffic, they have then accepted responsibility for delivering that traffic. (Note, it would be nice if there were an "oops" command so that a mistakenly downloaded message could be re-enabled on the BBS if the user decides before logging off that he can't handle it after all.) >Tod Olson, K0TO >ARRL Director, Dakota Division Unrelated note: It's very refreshing to see a Director actively participating here. Welcome! Gary -- Gary Coffman KE4ZV | You make it, | gatech!wa4mei!ke4zv!gary Destructive Testing Systems | we break it. | uunet!rsiatl!ke4zv!gary 534 Shannon Way | Guaranteed! | emory!kd4nc!ke4zv!gary Lawrenceville, GA 30244 | | ------------------------------ Date: Thu, 7 Apr 94 18:57:00 -0800 From: ihnp4.ucsd.edu!usc!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nntp-server.caltech.edu!news.claremont.edu!kaiwan.com!ledge!bob.albert@network.ucsd.edu Subject: RTTY for a beginner. To: ham-digital@ucsd.edu Yes, RTTY is usually FSK or AFSK. The common frequency shifts are 170 Hz (current) and 850 Hz (somewhat obsolete). It uses a 5 bit Baudot code, the details of which are in most ARRL handbooks. As a matter of fact, you would do well to pick up a copy and see what's in there on the subject; at least the older books had a good description. 73 DE K6DDX ------------------------------ Date: 8 Apr 1994 11:19:35 +0100 From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!uknet!acorn!not-for-mail@network.ucsd.edu Subject: sexually explicit talk To: ham-digital@ucsd.edu In article <765776764snx@skyld.grendel.com> jangus@skyld.grendel.com (Jeffrey D. Angus) writes: >In article bgould@iat.holonet.net writes: > > I don't have a liscense, but I bought a ham radio recently and was thining > > about opening sexually explicit gay chatline through info packets over the etc .. It seems such a shame to leave out the people from the two remaining flamethreads, so how about encrypting the traffic and sending it CW ? -adrian :-). ------------------------------ Date: Fri, 8 Apr 1994 12:54:24 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!news.unige.ch!ugun2a!pfund@network.ucsd.edu Subject: TCP/IP <--> FBB ax.25 link To: ham-digital@ucsd.edu In article <01HAOY3WODEAP1KTAW@rivendell.otago.ac.nz>, HOSPICE@rivendell.otago.ac.NZ writes: > Re: Subject: TCP/IP-f6fbb (ax25) link, how do you do it ? > > Daniel writes: > >>Would anybody know how to manage forward between a tcp/ip STATION >>and a f6fbb BBS without being declared as a BBS (eg, when you send out >>to the f6fbb BBS the command sp xxxxx < hb9vbc @ hb9vbc, it immediately >>advises the sysop and tells you that they don't forward to hb9vbc bbs!) >>Where does this have to be fixed ? > > Sending SP ZL4ABC < ZL4DEF @ ZL4GHI to an FBB BBS results in an msg labelled > like this: > > Message Choice - [*] > Msg # TSL Size To @BBS From Date/Time Subject > ------ --- ---- ------ ------ ------ ----------- ---------------------- > 25493 PNL 0 ZL4ABC@ZL4GHI ZL4DEF 940401/00:58 TEST > > As you have discovered, unless the FBB has a forwarding path set for the > @BBS, then it goes nowhere and the sysop gets a msg. > > Posting the same SP on a JNOS station produces a msg for ZL4ABC on that > JNOS station, with the msg being labelled as coming from ZL4DEF@ZL4GHI. > > If you could state your intent in posting that address format to an FBB, more > useful help may be possible. > Yes, I would exactly like to do that, automatically from NOS. Send the fbb bbs a message with the from BBS that has the same address as that fbb BBS. Example: I'm a NOS user, so I would be declared hb9vbc @ hb9vbc.ampr.org I also use an AX25 BBS called hb9iap.srom.che.eu, so I would like to smtp the ax25 bbs and tell NOS to use instead of the form sp xxx < hb9vbc @ hb9vbc the form : sp xxx < hb9vbc @ hb9iap. Is this possible ??? -- __ /// Daniel Pfund Internet: pfund@uni2a.unige.ch __/// University of Geneva, Economics AX25: hb9vbc@hb9iap.srom.che.eu \\\/ only AMIGA makes it possible ! ham radio amateur ------------------------------ Date: Fri, 8 Apr 1994 12:46:09 GMT From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!henrys@network.ucsd.edu Subject: TCP/IP from car w/PK-88 (Help) To: ham-digital@ucsd.edu Andrew J. Doane (adoane@interaccess.com) wrote: : I have just recently purchased a laptop, and since I have a PK-88 here : I have not used for a year or so, already have a 50w VHF radio in the car : that doesn't get much use (I'm a UHF nut), and I already have a TCP/IP : address allocated to me, I would like to use TCP/IP from the car. Andrew, (This has nothing to do with TCP/IP.) I thought that I was nuts for running CW from the car :-) And now back to your normal thread. Good luck, Smitty, NA5K/m -- ----------------------------------------------------------------------- | Henry B. Smith - NA5K henrys@netcom.com | | Dallas, Texas | | | | "I'm not sure I understand everything that I know" | ----------------------------------------------------------------------- ------------------------------ Date: Thu, 7 Apr 1994 20:31:19 +0000 From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!uknet!demon!llondel.demon.co.uk!dave@network.ucsd.edu To: ham-digital@ucsd.edu References <5155Jc1w165w@aznet.stat.com>, <765383670snz@topsy.demon.co.uk>, <2nupb4$1mp@gopher.cs.uofs.edu>uk Subject : Re: TNET-X1J In article <2nupb4$1mp@gopher.cs.uofs.edu> bill@triangle.cs.uofs.edu (Bill Gunshannon) writes: >There was talk a while back about someone working on a version of TNET-X1? >that would work in the DR-200. Has this ever been done?? > That was me.... I have the source, I even have a DR200 but trying to get hold of a Z80 C compiler which will do the necessary tricks for overlays etc to get the code to fit is not proving quite so easy. I daresay if I spent enough money I could get a commercial offering capable of doing it but it would be a lot of money for a one-off project. I did try the public-domain Hitech C (running under a CP/M emulator on my PC) but that won't do the necessary tricks. I haven't found a decent Z80 cross-compiler for the PC yet so I am open to suggestions. Dave -- ***************************************************************************** * G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on * * dave@llondel.demon.co.uk Internet * until the end. Then stop. * * g4wrw@g4wrw.ampr.org Amprnet * (the king to the white rabbit) * ***************************************************************************** ------------------------------ Date: 7 Apr 1994 17:19:10 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com!hanko@network.ucsd.edu To: ham-digital@ucsd.edu References , <1994Apr5.222105.9528@newsgate.sps.mot.com>, ko Reply-To : Hank_Oredson@mentorg.com Subject : Re: NTS traffic on packet In article , dts@world.std.com (Daniel T Senie) writes: |> In article <1994Apr5.222105.9528@newsgate.sps.mot.com> kinzer@dtsdev0.sps.mot.com (Dave Kinzer) writes: |> >In article dts@world.std.com (Daniel T Senie) writes: |> Actually, the need for rescuing is a BIG problem, and indicates a failure |> in the network. At least SOME of the BBS systems show the NTS traffic as |> listable on EVERY node it passes through, for the duration of the stay |> at that node. If this were not the case, and a link between nodes were |> down (or the BBS at the other end of the link is down) then the NTS message |> would be delayed, and not be visible to any user, until the link or distant BBS |> returned. This would result in a delayed NTS message, with NO confirmation |> or information to the originator that the message is not getting through. Sounds to me like some NTS folks need to talk to the BBS sysops involved, and give them some guidelines on how NTS would like it's traffic handled within the BBS network. I would expect NTS to contact me (as well as the other BBS authors) about these issues; they have not done so. |> The skepticism on the part of many NTS operators comes from the need to |> trust a distributed system of unknown (at the moment of sending) reliability |> to get the message through. Have there been major problems? Does the NTS liason who takes the message and delivers it notify the NYS liason who put it into the BBS network? If they do, what sorts of problems are seen? At least in this area of the country, I hear a lot of whining from the NTS folks, but when I look at my own BBS system I see *all* NTS traffic clearing within 24 hours - to any part of the US and CANADA. The only traffic that remains "stuck" is traffic destined to my local area. Sometimes no NTS liason checks the BBS for several days. |> I use packet nearly every day to communicate with folks, but often will |> ask when on a voice mode if they got the message or not. |> Why not ask on packet? The SR command is not really all that hard to type. |> As noted above, it is not "temptation" that causes trouble. If an intermediate |> BBS allows a user to list the traffic, and to KILL the traffic, then that |> user has assumed responsibility for the message. It does not matter if the |> message gets to the "right" BBS near the destination zip code, just so long |> as SOMEONE is able to pick it up, and kill it, and have that ONLY HAPPEN |> ONCE! And if there is any doubt about who took the traffic from the BBS system, the BBS log files can confirm who took it, when they took it, etc. If NTS wants confirmation of the point of exit from the BBS system, a simple SR and message with "I took your number xxx" is all that is required. ... Hank -- Hank Oredson @ Mentor Graphics Internet : hank_oredson@mentorg.com Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM ------------------------------ End of Ham-Digital Digest V94 #105 ******************************